SOLID Considered Harmful Part 1: S....

SOLID principles, developed by Robert Martin a.k.a. "Uncle Bob", are amongst the most cited by programmers. I believe that many of them are misunderstood, misapplied, overrated, and all too often they much less important than other software engineering principles.

In this post, let's consider the "S", the Single Responsibility Principle.

S: Single Responsibility Principle

This was inspired by early (1972) work of David L. Parnas (see page 24)

"We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others."

I totally agree with this. You should abstract / encapsulate the difficult decisions, especially those that are likely to change. For example, if you are using some hot new startup's miracle Cloud Database, that is likely to change in a few years, and should be abstracted. A "module" should encapsulate only one such decision (or possibly zero), separating it from other difficult decisions.

Originally (2003) Uncle Bob expressed this as "A class should have only one reason to change." Which begs the question, "what is a reason to change"? In this followup he argues that the "responsibility" is this: "who must the design of the program respond to?". He nicely elaborates:

"When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function."

He provides yet another nice phrasing:

"Gather together the things that change for the same reasons. Separate those things that change for different reasons."

Did SRP improve upon the work of Dr. Parnas? Unlikely.

The principle that a module should encapsulate a single design decision that is likely to change is understandable, pragmatic, and realistic. It needs little elaboration. A programmer should understand what is a "design decision". In contrast, the term "responsibility" is less clear, and "Single Responsibility Principle" is overly simplistic, frequently misunderstood, and begs the question of "what is a responsibility", which has needed continuous elaboration by Dr. Bob. After much struggle, he finally got it right in "Gather together the things that change for the same reasons...", though he should add a "likely".

It is clear from newbie questions on Stack Overflow that the "Responsibility" part is seldom understood (can't blame them) and most budding programmers only respond to the "Single" part the principle. A general opinion of the Stack Overflow veterans is that SRP is horribly misunderstood.

Plus, the SRP, as commonly expressed, e.g. Wikipedia usually leaves out the "likely to change" clause. So it deters a programmer from including functionality that is unlikely to change.

Conclusion: SRP isn't "bad", but it took a clear concept, and made it confusing.

SRP, if well understood, is a fine concept. In practice, SRP all to often scares programmers to create classes that don't do much, leading to an Anemic Domain Model, which, ironically, was first described as an anti-pattern by, you guessed it, Uncle Bob.